It was added in #118204

@ericsnowcurrently, do you remember if there was a reason for this assert?
Can we assume you added asserts when exploring which code paths are taken, and since we had no tests for modules with a dot added via PyImport_AppendInittab, this assert just never fired?

@itamaro: I'd be a bit more careful in _testembed: from test import create_static_module assumes that the test package is available, which is not always the case. I don't think you'd necessarily want to run testembed without test, but I also don't think we should add an arbitrary requirement/assumption.

Could you add a different containing package to the inittab?

@itamaro: I'd be a bit more careful in _testembed: from test import create_static_module assumes that the test package is available, which is not always the case. I don't think you'd necessarily want to run testembed without test, but I also don't think we should add an arbitrary requirement/assumption.

Could you add a different containing package to the inittab?

Can _testembed even be meaningfully used without the test package? (and test_embed.py driving it)

Regardless, I agree this is an awkward way to test this. I think it would make more sense to add a net new test case for this functionality, if we decide it's a desired functionality we don't want to regress.
Happy to do that when we reach such a conclusion, but let's first make sure the assertion is safe to remove!

I'd say that as an embedder, you're probably in the best position both to test this, and to decide if it's desired functionality.

Allowing submodules in inittab looks doable. (@brettcannon, do you have any thoughts on BuiltinImporter loading submodules?)

Allowing packages, on the other hand, might be worth more discussion -- that would probably need new API, since struct _inittab doesn't have the is_package bit.

Can _testembed even be meaningfully used without the test package? (and test_embed.py driving it)

It can! Not sure if it's meaningful to run it without the test package available, but I do use the CLI on its own when debugging.

Anyway that's not the question to ask. More coupling bad, self-contained good :)

thanks @encukou
since the same assertion is triggered when importing submodules and modules within packages if they use inittab, addressing the issue for one use-case should also apply to the other!
note that the "modules in packages" use-case is not the same as "inittab-based packages". the name & initfunc in inittab will always be used to create a module or submodule, and the existence of a parent package is orthogonal.
I will look into adding dedicated test cases for both scenarios (and decouple from the test I hijacked), although I'm not quite sure how to set things up such that some package will be available at runtime for _testembed to use (without assuming something about the external environment, or having test_embed arrange things accordingly before invoking _testembed)

Allowing submodules in inittab looks doable. (@brettcannon, do you have any thoughts on BuiltinImporter loading submodules?)

I think it's fine to add. I suspect it didn't have it just because the need never came up.

@encukou I added new dedicated tests

Looks good, thank you!

Thanks @itamaro for the PR, and @encukou for merging it 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

Thanks @itamaro for the PR, and @encukou for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

Sorry, @itamaro and @encukou, I could not cleanly backport this to 3.14 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 27f62eb711720c215f9798ae30728ee5a1b4d442 3.14

Sorry, @itamaro and @encukou, I could not cleanly backport this to 3.13 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 27f62eb711720c215f9798ae30728ee5a1b4d442 3.13

GH-141986 is a backport of this pull request to the 3.14 branch.

GH-141987 is a backport of this pull request to the 3.13 branch.